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GENERAL DESCRIPTION 


The B1000 data communications subsystem provides an interface 

between the network controller and any executing MCS on the 
system. Fhe character™oriented header information which the MCS 
reads or writes in 1ts communication with the network controtter>» 
the remote files in 1ts own networks and the MCP obasicaily 
constitutes the MCS interface that is described in this product 
specification. The MCS interface is composed of the various 
messages required for any queries or changes in the status of 
remote stationse 


The minimum requirements for this datacomm environment are an NOL 
handter and a user program which opens aremote file with headers 
Can MCS). There is no restriction on the number of remote files 
With headers that may be opened on the systems although there is 
a maximum of 20 remote files that can be concurrently associated 
with any one station. In a system composed of several MCSs» a 
station may be associated with more than one of them in a hier 
archical manner. 


In general» the network controller handies the Line protocol and 
the MCS» in cooperation with the network controller» handles the 
attachment of remote stations to their respective remote files. 
Remote file I/Os standard to the 81000 systems is controlled by 
the operating system through a queue file mechanism that is 
transparent to the user and therefore not discussed in this 
document. — 


An MCS) program wttt fulfiti some or att of the following data 
communications needs: 


- Message switching 


- Logical attachment of a station to a remote application 
program or system of programs 


- Network reconfiguration 
- Audit and recovery 
- Network statistical analysis 


- Communication with the operating system. 


REMOTE FILES 


Remote files are the means by which programs use the NDL datacomm 
subsystem to transfer information from remote terminals to user 
programs Cor vice versa). MCS-type remote fites are distin-| 
guished from ordinary remote files only by the special headers 
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that allow them to affect the flow of messages. 


MCS interface is enabled by opening a remote fitie with headers 
that has an external file name which matches a file declared in 
the file section of the executing network -controiter. All 
Stations listed in the family statement for that file are 
controtled by the MCS. The 50-byte header that precedes data 
Messages allows the MCS to access tallies» toggtes and other 
information relevant to the station originating the message. 
Nondata messages consist only of the varitable-tength header. 


Dummy remote files» ise.» with no stations specified» are allowed 


as tong as the program opening the dummy remote file (without 


headers) has been zip~executed by an MCS~type program. The MCS 
is expected to direct the assignment of stations to that file by 
approving or disapproving the open of any remote station that 
wishes to be attached to that file. 


“RESOURCE SHARING 


Where multiple MCSs are executing on the same system» there is an 
established protocot which allows one MCS to attach stations to 
anothers The protocol is based upon the concepts of “primary” 
and “secondary” and these terns refer to the relative responsi- 
bilities of two MCSs in the control of a remote stations. 


Since users may sign on or attach to a series of MCS~type files» 
primary fites (with some restrictions noted below) are distin~ 
guished from secondary fites only by signal characters and by 
their relative positions in the master List of attachments kept 
_for each station in the remote network. The primary file is the 
fast remote file on the master list to which the station is 
attached and the secondary file is the next~tortlast. By default» 
all interface messages go to the primary files and» if the first 
character of the message matches the signal character defined for 
the secondary file Catl secondary fites must have a signat char= 
acter)» the message goes to the secondary file. The advantage of 
this configuration is that a remote station can stilt communicate 
with the secondary file even though it has a primary attachment 
to another remote file. 


Secondary Fades are restricted to remote files opened with 
headers since they must have signal characters associated with 
them» and primary files may be either ordinary remote files or 
remote files opened with headers. In a series of remote attach 
ments done by an individual station» there is a timit of one 
attachment to a remote file without headers: it must be the 
primary file. If atl of the attachments are to MCS-type remote 
files» there is a limit: of 20 attachments for one remote station. 


Primary and secondary. protocol is waiataried through master. 
list that is updated by the network controller each pre a renote 
piarran attaches or. detaches bike! from an NCS or a ‘remote file. 
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When a station signs on or attaches to a remote file» the file- 
name is added to the list and a signal character is associated 
with it if it is an MCS. If a third attach/sign on is made» the 
primary and secondary designations are reconfigured. . After. 
redefinitions the original MCS does not have any current respons 
sibilities where the remote station is concerned and is inacces~ 
Stble from that station. 


When a remote station is detached or closed» the Last entry is 
deleted from the list and primary and secondary are reconfigured 
from the master tist. In this way» the original MCS Cin a series 
of three attaches) is maintained on the tList and the _ = final 
close/detach must be from the first Coriginal) MCS. MCSs 
designed to inhibit the primary~secondary option do so by denying 
all opens on remote files with headers. 


‘BASIC IERMINOLOGY 


This subsection defines most of the basic terminology that is 
used in this product specification. It also references retated 
publications that would be hetpful to those who are unfamiliar 
with those terms and concepts. 


MCS Message Control System = Any program 
| which opens a remote fite with the 
header option and thereby controls the 
Stations in that remote file. | 


NC Network Controller - The program gener~ 

| ated through compitation of an NOL 
(Network Definition Language) program. 
The NC handles the line discipline § for 
the data communication devices of a 
system and interface queue between MCS 
and operating system. Refer to P.5. 
2212 5223» 81000 NDL and 1073715» NDL 
Reference Manual. 


Remote File A file declared in a program which» tn 
conjunction with the network controtter>» 
provides inputs output or I/70 with a set 
of data communication devices. Refer to 
P.5- 2212 5462 B1000 MCPII and 
1089992, Data Communications Information 

Manual. 


Headers — 7 An option on a remote file which allows 
a System control functions and provides a_ 
50“byte header on alt data messages 
moving through that remote file. _ 
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Primary File 


Secondary File 


Controltiing Remote File 


Attach Initiator 


User Program (U.P.) 


—LSN 


RSN 
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The file to which a station was most 
recently attached or included in an 
OPeANe Normal input goes to the primary 
file. | 


The fite to which a station was just 
previously attached or inciuded in an 
opens i2@.» the penultimate attachment. 
The secondary file must have headers and 
will have approved the attach or open of 
the primary fite. Input whose first 
character matches the signal character 
(not blank) designated in the primary 
file's attach or open wiil go to the 
secondary file. 


(CRF) is the file with headers to which 
a station was most recently assigned» 
either with an attach or with an open. 
If the primary file has headers» it is 
the CRFs otherwise» the secondary file 
is the CRF. 


is the file which writes an attach. 
normally denotes a program which has 
opened or 1s opening a remote  “fite 


Without headers. 


Logical Station Number ~ The number by 
which the network controltier uniquely 


identifies a station for normal transac~ 


tions. LSN*s begin with 7001" and 
proceed sequentiatily through alt the 
Stations declared in the Station section 
of the NDL controtier. 


Relative Station Number - The number by 


which a user program with a remote file 
using a remote key uniquety identifies a 
station.» An RSN equal to 0 implies a 
control message. An RSN equat to 1 


implies the first station in the file's 
family statement.» RSN*'s proceed sequen~ 


tiatly through the stations delineated 
by a file's family statement» except 
that a controtling remote file may 
modify the LSN.LIST and thereby modify 
the RSN*s of the remote file. If a 
station is detached from a file with a 
remote key» the RSN*s remain unchanged. 
If a station 1s attached to a file with 


aa a remote keys the new RSN will peo its 
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old RSN if it were attached previously; 
otherwise» it will be one larger than 
the greatest RSN previousiy associated 
with the file. 


RELATED DOCUMENTATION 


NAME | NUMBER 
61000 Network Definition Language P.Se 2212 5223 
81000 NDL/Libr ar y | PeS-e- 2212 5215 
81000 NDL Reference Manual 1073715 
Data Communications Reference Manual 1089992 
B1i000 Data Comm Audit PeSe 2212 5421 


-Bi000 MCPII | | P.S. 2212 5462 
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MESSAGE TYPES 


This section specifies the record formats of the messages read 
and written by the MCS as it communicates with both the network 


controller and the remote stations in its remote file. 


There are three types of record formats: data» control and user- 
defined. Data record format is used in the transfer of informa- 


tion between network controllers and remote stations and in this 


area the MCS may read or write the record» depending on the 
source and destination of the messagee. Control records are 


defined by name and represent a specific purpose and actionr 
@eger a detachereply. Useredefined record format is used for 


communication between an MCS and ae user remote file without 
headers ands as 1ts name indicates» it allows the user program to 
establish the purpose of the communication. | 


All messages recognized and written by an MCS are iisted by type 


and format. 


Table 221 MESSAGES READ 


MESSAGE TYPE FORMAT 
QUTPUT MESSAGE (from REMOTE FILE) 700" DATA 
INPUT MESSAGE Cfrom STATION) "oe DATA 
INPUT LOGICALACK | roar DATA 

GOOD.RESULTS.»REPLY nO5" DATA 
-RECALLED.MESSAGE "06" DATA 

UNPROCESSED.QUTPUT MESSAGE | "o7" DATA 

OPEN "10" CONTROL 

ATTACH : maa" CONTROL 
ATTACH.REPLY | | as ie CONTROL 

DETACH | os CONTROL 
‘DETACH.REPLY | nyse CONTROL 

CLOSE | 7 "16" CONTROL 
STATUS.REPLY ot "21" CONTROL 
-CHANGEsREPLY | "23" CONTROL 
RECALL «REPLY na5r CONTROL 

REMOVE.REPLY "270 | CONTROL 
REMOTE .FILESINFO.REPLY — "29" CONTROL 
LINE.RELEASE.REPLY | oa CONTROL 


REMOTE.FALEsINTERCOMMUNICATION "50" - "99" USER~DEF INED 


edo agen een era mE RA et eT MAM TOUR ESLOREED EN DCO ee POITIN MENT ORNL Oe POTS Ure ne Saen Sbt NE Ae cers eter em eer ee nee eran eam Se iesracanaees 
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Table 2.2 MESSAGES WRITTEN 


MESSAGE 


FORMAT 


TYPE 


GQUTPUT MESSAGE (to STATION) "90" DATA 
INPUT MESSAGE (to REMOTE FILE) "gi" DATA 
LOGEICALACK.REPLY “93" DATA 
GUTPUT GOOD.RESULTS "O4" DATA 
 OPEN.REPLY ae Fg CONTROL 
ATTACH Sle CONTROL 
ATTACH.REPLY ne Os CONTROL 
DETACH "14" CONTROL 
STATUS "20" CONTROL 
CHANGE | i CONTROL 
RECALL "24" CONTROL 
REMOVE "26" CONTROL 
REMOTE.FILE-INFO a 3 a CONTROL 
LINE.RELEASE "30" CONTROL 
REMOTE.FUILE. INTERCONMUNICATION “20™ «= =99" USER“DEF INED 


KEY (0 ABBREVIATION 


In Tabies 2-3 through 5.1» 
tions are used: 


the foltowing abbreviations and nota. 


Network controtller/ooperating system interface 


to SET that fietd. 

under an "R™ implies that it is appropriate for that program 
to READ that field. 

under a "W" implies that it is mandatory for the MCS to SET 
that field before sending the message. | 

' implies a numeric EBCDIC character field (Bit 8) 

dmplies an EBCDIC character fietd (Bit 8) 

denotes iterations of the Same field» one for. each 

remote station | | 


NC - 
~ MCS - Remote file with HEADERS 
USER - Remote file without HEADERS 
R - Read 
W- Write 
Notes 
"a2" under a "w" implies that it is aperopeEnare for that program 
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DATA MESSAGES 


The types of data messages which an MCS reads and writes are as 


follows: 
TYPES WRITTEN DESTINATION AND FUNCTION 

00 An output message to any station in its 
remote file. 

01 | An input message to any remote file. The 
destination of the message 1S indicated by 
the number in the remote.file.no field. 

03 | A logicalacksraply. message to the network 
controller. This message should attow the 
relevant request to acknowledge receipt of 
the message via an ack to the station. 

O4 A goodsresults message to the network 
controller. This message acts tike an output 
message except that positive receipt of the 
message by the station produces a good.re- 
sults.reply. 

TYPES READ ORIGIN AND FUNCTION 

00 An output message from a remote file whose 
open it approved with participating set to 
ae See 

01 An input message from one of the fottowing: 


A primary station when the signal char- 
acter 1s not used. 


A secondary station when the signal char- 
acter designated in the open or attach or 
attacherenly is the first character of 
the message. 


‘A remote file with headers. 
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02 An input logicatack message from the network 


05 


06 


O7 


The data message 


—MESSAGE.TYPE 
VARIANT 

LSN 

TEXT.SIZE 
REMOTE.FILE.NO 
TIME 

TRAN.NO 

ERROR 

—TALLYS 
TOGGLES 
TERMINAL .TYPE 
END_KEY 
FILLER 

TEXT 


*¥ F F Fe FR HF HH HF HR FR 


controtter. This message is received when a 
request executes a terminate tlogicatack. If 
the primary has headers» it receives this 
messager otherwise» if there is a secondary 
file it gets the message. | 


A good.resuilts.repiy message from the network 
controller is received upon successful trans- 
mission of an output message to a station. 


The message is received only if the 
goodresults bit in the message or station 
Was Sete If the primary remote fite has 
headers» this message 1s received by the 


primary filer otherwise» the secondary file 
receives ite 


A recalled.message from the network 
controtitler. Recailed.messages fotlow the 
recait.repiy message» The number of recaited 
messages 1s indicated in the recalli.reply. 

An  unprocessed-output message from the 
network controller. | When the network 
controller is DSed» it sends output messages 
to the appropriate controittling remote file 
before sending an EOF. 


format is defined as: 
Table 321 DATA RECORD FORMAT 


NC-MCS MC3"NC MCS“USER USER“MCS FIELD LENGTH 


W x W R W KR W R PIC 
te + te + (*) (*) x 99 
ke & * ke - - 9. 
x k ke & («) (*x) * 999 
k« + & + {x) {*«) te 9(4) 
ie te te + - - 999 
& - - 9(7) 
te - - 999 
& - = XX 
x te “ ~ 9€9) 
* & & - - —69C8) 
. - - 99 
te X 
: Xx€5). 
ie te te & te & t f 


XCTEXT.~SIZE) 


(33 
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the: sapenenesieed fields in Table 3.1 for user remote files 
indicate the three fieids in the remote keys The remote key has 
the following format: 


RSN 93) 
TEXT .SIZE 9(4) 
ME SSAGEsTYPE 9(3) 


RSN ts converted to LSN by the remote file interface. 


The semantics of the fields in the header are: 


field indicating the following: 


VARIANT A 
= 1 7°" make program memory resident 
= 2 "= make program disk resident 
= 3 -- cause EOF branch 
= 4 =" cause exception branch 
= 5 =" include text in good.results.repl y 
LSN | | The logical station number to which the 
3 data belongs. It must be set on output 
and good.results messages. | 
~—oTEXT.SIZE The number of characters in the text 
field. | | 
REMOTE.FILE.NO The number of the remote file where the 
message came from or is going to. It 
must be set on input messages. 
TIME The time in 20-bit counter format when 
| the network controller processed _ the 
messageSe 
 TRAN.NG The transmission number that belongs to 
| : the message. 
ERROR A lo~bit field extracted from the result 
7 descriptor which indicates exception 
conditions. The meaning of the bits of 


this field are as follows Cbit O=most 
Significant bit): | 


BIT EXCEPTION 
parity error | 
buffer overfiow 
read memory parity 
time out = 

- break | 

 eend of buffer 


OME WN me © 
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TALLY 
TOGGLE | 
TERMINAL.»TYPE 


END_KEY 


TEXT 
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6 loss of DSR 

7 toss of carrier 
8 address error 

9 . transtate error 
10 format error 

1i | read not ready 
12°15 not used 


The semantics of taily» toggle and 


terminal.type are the Same as in 
previous releases: the taily field 
represents the first three station 


tallies in 3-character decimal format. 
The toggle field represents the first 
eight station toggles as “0" or "1". 
Terminal.type is the twordigit designa- 
tion that identifies each class of 
terminals. 


Valid onty for MCS that deals with 
COBOL/74 programs on a SEND. 


i 


"9" if no ending indicator. 

"1" if end of segment indicator. 
"2" if end of message indicator. 
"3" af end of group indicator. 


Wout 


The character string which is ordinarily 
displayed on the remote screen or the 
local operator display terminal COOT). 


ey 
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CONTROL MESSAGES 


OPEN MESSAGE 


The open message is the mechanism for creating new remote files. 


The operating system receives an open from a program and deter- 


mines that the device is a remote file. A remote fite open 
message is then formulated and passed to the network controtler 


which takes the following actions: 


1. If the file is knowns it modifies the message to indicate 
the appropriate station tist> if unknowns the open is 
disapproved with file aissing. 


2. Verifies that the open message is valid. If not» it 
disapproves the open. | 


3. If none of the stations in the open are assigned to an 
MCS» it approves the open and creates a new remote file. 


4. If some of the stations in the open are assigned to one 
MCS and the rest are unassigned» it forwards the open 
message to the NC5. | | 


Se If the stations in the open are assigned to more than one 
MCS and the program attempting -the open was not zip 
executed» it disapproves the open with file locked. 


6. If the program whose open 13 being processed was zip 
executed by an MCS» then the tist of stations in the open 
is examined. If all the stations in the list belong to a 
different MCS» then the open is forwarded to that 
program. If a discrepancy exists» then the open 1s 
forwarded to the MCS that zipped the program. 


7. If it is a dummy file with headers but was not zio- 
executed by an MCS» the open 1s approveda 


8. If it is a dummy file without headers and the program was 
not ziptexecuted by an MCS» it will be disapproved. This 
is done because there is no way to attach Stations to the 

remote fite after the opens 


QPEN REPLY 


If the open is passed to an MCS» an openereply is expected. The 
“MCS must approve or deny the open. It may» in additions modify a 
number’ of other fields as specified. in the diagram on the open. 
format Cunder MCS-W). If a denial is sent» no changes will be 
fade» the. denial will ‘be forwarded to ‘the operating preter which 


tad 
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will deny the open to the opening program. A signal character 


indicated in the opensreply enables the station to communicate 


with the MCS. If open.etynpe is output or if participating is set» 
no changes wilt be made to primary or secondary assignment $s. 


If both participating and headers are set» the open will be 
disapproved by the network controller. and a close with open.error 


set will be dispatched to the MCS. 


When the network controtter receives an open.-repty from an MCS» 


it rechecks all fields relevant to itsetf and the operating. 
system. If the MCS made an error in formulating the reply» the 


approval will be changed to denial and a ctlose will be sent to 


the MCS with open.error = "1". Otherwise» the new remote file 


will be created and the reply forwarded to the operating system. 


OPEN WITH HEADERS 


An MCS may approve an open with the headers option sets indi- 


cating another MCS. At this time» the primary file is the file 
whose open was approved and the secondary file is the file which 
approved that open. All messages whose first character is the 
designated signal character go to the secondary file. All others 
go to the primary file. Then» if the second MCS approves an open 
with that station or attaches that station to a third remote 
file>, the first MCS is Left out» the second MCS becomes the 


secondary file and the new remote file becomes the primary file. 


An exampte of secondary attachment would be a station running 
under the ittlustrative MCS which first signs on to a special MCS 
which» in turne retrieves certain types of information from a 
data base on command and then from the second MCS signs onto an 
inventory review program. As the user reviews the inventory» he 


may at any time type in his signal character and query his data 
base through the speciai=purpose MCS. In order to contact the 
iilustrative MCS» however» he must first sign off from the inven 


tory review program. 


An example of a participating open would be a station running 


under the itlustrative MCS signs onto a special MCS which formats 
messages according to terminal type» sets up forms» displays data 


attractively» etCe» and from this second MCS signs onto the 
inventory review program. The second open 35 approved with 
participating set to "i". In this case» primary messages are 


sent to the special MCS and secondary messages still go to the 


ddlustrative MCS. 
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OPEN WITH SIMPLE HEADERS 


A remote file with SIMPLE_HEADERS is used as a headers file with 
a few exceptions. 7 


A 50-byte message header must be prefixed to every message sent 
or received by the program using the file. The only exception to 
this is that the result of a "TERMINATE ERROR™ done by the NC 
caused an “QN EXCEPTION” condition to be set for the files» as 
with a simple remote fite» instead of the usual procedure for a 
headers file. 


A SIMPLE_HEADERS fite will not receive unsolicited responses, 
that is» no OPEN» CLOSE» ATTACH» DETACH» or LOGICALACK messages 
will be queued for the file. | 


A SIMPLE_HEADERS file may set TALLIES and TOGGLES in the message 
header» as well as issue GOOD_RESULTS» REMOTE_FILE_INFO>» and 
STATIGN_STATUS messages» but may not write ATTACH» DETACH» 
CHANGE» RECALL» LINE_RELEASE or COBOL74-related messages. CAL 
COBOL74 QUEVES will be SIMPLE _ HEADERS files.) 


One more difference between SIMPLE _HEADERS and fuil headers files 
1s that in the case where the OPEN for a remote file with 
SIMPLE HEADERS is forwarded to an MCS» the MCS may approve the. 
OPEN with "PARTICIPATING" set. 


DUMMY REMOTE QPEN 


If the MCS approves an open with current stations = 0» then the 
open wilt be approved with no stations initially attached. Fach 
message directed to that remote file witl cause the MCP to deter- 
mine whether tha LSN<">RSN association has been estabtished 
adready in the FI3 and establish it if necessary. The message 
will then be processed as usual. This facility aliows a remote 
file to be opened with no stations attached initially and 
messages then to be sent Cunder direction of the approving MCS) 
to the file without the indicated station having aoe explicitly 
attached by the MCS to the remote file. 


OPEN/OPEN-REPLY FORMAT 


‘The formats for the open and open-ereply messages are shown below. 
Included are indications of relevant fields and aL 1s oan 
exptanation of paste fietd's meaning. 
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Table 


—MESSAGE.TYPE 


- OPEN.TYPE 
OPEN.TIME 
- PARENT.JO8.NO 
 PROGRAM.JOB.NO 
PROGRAM. NAME 
HEADER. OPTION 
SIMPLE -HEADER.OPTION 
USE.REMOTE eKEY 
RESIDENT 
—*USER.REMOTE.FILE.NO 
SIGNAL. CHAR 
-APPROVE.DENY 


 DENTAL.REASON 


PARTICIPATING 
GOOD.RESULTS 
MAX. STATIONS 
CURRENT. STATIONS 
LIST.TYPE 
FILENAME 
PROTOCOL.TYPE 
SESSION 

— STATION*LIST 


And 
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4.1 OPEN/OPEN.REPLY 


NC“MCS MCS-NC 
W R PIC 
+ ik 99 


A 


* ree 2 HF RF RR RR ES 
* heh P ® ee HH RR & 
4 
ao 
Wi 
GS 
ad 


ee * + & 
ewe ee eR He 


: | 9999 
t t 999 (CURRENT. 
STATIONS) 


ey + ® * YH RH H 
re ee F HH H 
~*~ 
~~ 
poe 
oS 
ed 


The semantics of the fields of the open message are as follows: 


 OPEN.TYPE 


 OPEN.TINE 


PARENT. JO3.NO 


‘PROGRAM. JO8.NO 


PROGRAM. NAME 


Indicates the directions of data flow 
allowed the remote file: 


se Gis -- input only 
"2" -= output only 
"3" -- anput/output 


The time at which the MCP recognizes the 


file open. — 


The job number of the program that zip- 
executed the program opening the remote 
file or 70000000". 


The job number of the program opening 
the remote file. | - | 


The name of the program opening the 


remote files. | 
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HE ADER.OPTION 
“SIMPLE -HEADER~»OPTION 


USE~REMOTE.KEY 


RESIDENT 


USER.REMOTE.FILE NO 


SIGNAL.~CHAR 


APPROVE.DENY 
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A boolean indicating whether the file is 


allocated with MCS“type headers and 


functions. 


A boolean which» when set atong with 
HEADER»OPTION» indicates to the NC that 
simple headers are to be used. 


A boolean indicating whether the file 
includes the key option. The remote.key 
option ailows writes to specific 
stations and on reads tindicates’ the 
Station which sent the current message. 
For files without headers» stations are 
identified by relative station numbers 
CRSN'sS). 


A value indicating what to do on a read 
with no data: 


"1" -= keep program in memory 
ve" == roli program out to DISK 
"3™" =~ provide EOF branch 


The tlogicat file number which the 
network controller uses to identify the 
opening file throughout the remote’ file 
interface. The MCS must not change this 
field. 


Used by the network controller to iden 
tify messages intended for the MCS from 
a station. Blank implies no signat 
character. | 


Indicates to the operating system 
whether the open should be approved, 


"i" implies open approval. 
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DENTAL -REASON 


DENIAL -REASON: 


VIE WIN © 


won OO 


PARTICIPATING 


GOOD.RESULTS 


MAX»?STATIONS 


CURRENT.STATIONS 
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Indicates the reason for an open denial. 
The DENTAL.REASON may be set by an MC5 
to any of the following (Csome have no 
logical meaning to an MC5)3: 


MEANINGS MCP REPORTS AS: 
No reason NO REPORT 
File missing FILE MISSING 
File locked FILE.LOCKED 
Adapter missing  FILE.MISSING 
MCS denies FILE.LOCKED 
No room in NC for FILE.~LOCKED 
remote file 
Invalid LSN list FILE.~MISSING 
Too nested © FILE.LOCKED 
MCS missing | NQ REPORT 
Invalid station count NO REPORT 
A boolean indicating whether the 
approving MCS widt participate in the 
user program's I/0. It is set by the 


approving MCS and causes all input from 
the station and ali output from the 
remote file to be sent to the approving 
MCS rather than the user program. No 
changes are made to the primary or 
secondary files of the stations ina 
remote file open with partictpating set 
to silt al 


Set by the MCS to indicate that the 
network controiler | should. return 
gooderesults messages upon successful 
transmission of data messages to the. 
Station. 


The number of stations that can be 


attached to a given file. It is set by 
the program attempting to open the 
remote file as part of the file dectara- 
tion. 


The number of stations that are in the 
Stationetist to be originally attached 
to the file. Currentestations equal to 
"900" indicates a dummy file. This 


creates a file which only the approving | 
MCS Cor any MCS gaining knowledge of its. 


remote fite number) may talk to» and 
which Stations ou tater be attached 


Bye to. 
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LIST.TYPE : 


- FILENAME 


PROTOCOL.TYPE 


SESSION 


STATION.LIST 
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Indicates the method by which the user 
program specified his remote file. The 
values of this field can be: 


“g" -=- file name 
"1" -= station list by name 
"2° == station list by ULSN 


Type "0° is the only one currently 
implemented. 


A field providing the file name given by 
the user program. This name must match 
a file name declared in the file section 
of the NDL program which generated the 
controller untess the user program was 
executed under controt of an MC5. If 
the file name given does not exist and 


the user program is under control of = an 


MCS» then the open witli be passed to 
that MCS. However» the file name is not 
a unique file identifier. The stations 
in a given NDL file may be modified so 
as to be shared by two remote files or 
passed on to another remote file with 


the same name. In future releases» 


files may also be designated by station 
list» so reliance on file names to iden- 
tify remote files is not reconmended. 


Indicates the type of remote file inter- 
communication desired by the application 
orogram opening the file. 


(See Pe. Se 2219 0432» SMCS for an 
example.) 


The remote session number associated 
With the application program performing 
the open. It is "0000" if there is no 
session association. 


Contains the List of stations Cby LSN) 
included in the remote file. Each LSN 
occupies 3 characters in the List (See 
CURRENT.STATIONS above). 
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QPEN REVIEW CRITERIA 


When an open is approved without being sent to an MCS» the 
network controller verifies that: 


A. There is room in the remote file table as indicated by 
the max files statement in the NDL declaration section. 


Be. Current.estations is tess than or equal to maxestations; 
if not» it is set to maxestations. 


C. fhe foltowing conditions are true: 


le. the station exists 
and 2. the adapter is present 
and 3. the station is appropriate» i.e.» that 
ae the otd primary is null 
or be the old primary does not have headers and the 
secondary is null and the open.type 1s output 


De the file is not 2 dummy file without headers. 


Before an open is forwarded to an MCS» the network controtiler 
verifies that: | | | 3 


A. There is room in the remote fite table as indicated by 
the max files statement in the NDL declaration section. 


B. Currentestations is iess than or equal to max»stations» 
if not» it 1s set to max.stations. 


C. The remote file being opened» if it 1s a dummy fite» was 
Zip~executed by a program with headers. 


D. The following conditions are true: 


| 1. the station exists 
and 2. the adapter is present 
and 3. the station is appropriate» i.ee» that 
ae the primary is null (not all stations) 
or b.j the primary 18s the approving MCS 
or ce the primary does not have headers and the 
secondary is the approving NCS 
and 4- the nesting of open approvals and attaches is 
not too deep. | 


old 
cr72") 
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Before an open.reply is processed and approved for the user 
programs the network controller verifies that: 


Ae The open on Chis Peuaee re was sent for open approval 
Be. The MCS set approve.deny to “1" indicating approval 

C. Current.stations is less than or equal to maxestations 
De. Headers and participating are not both set 

Ee. The fotlowing conditions are true: 


1. the station exists 
and 2e the adapter is present 
and 3. the station 1s appropriate» ies,» that 
ae the otd primary is nult 
or be the old primary is the approving MCS © 
or ce the cld primary does not have headers and 
the old secondary is the approving MCS 
and 4.2 the nesting of OPEN approvals and attaches is 
. not too deep | : 
and 5.2 aif participatings the primary is the approving MCS. 


The foltowing tables summarize the action that the N.C. will 
take when it receives an OPEN or an OPEN.REPLY. 
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> OPEN 


mew ee ee ee ee ee ee ee ee ee Ue EB Ue EE eB Ee ee Oe Oe OO UE UE OU 


i ALL | SOME OR ALL LSON*S 1 SOME OR i 
1 LSON*S ¢§ BELONG TO SAME CRF FT ALL LSN*S 3 
\. AVAIL. Leserseece sere ees") BELONG -10 4 


{ IRF = CRF IRF /= CRF { OTHER RF 1 

SS SS ae Se ae aS eS eee eS == (=<<es= acdc | 
1 ZIPPED OR | i j { i 
1 EXEC BY 1 A 1 FCRF i DFL j DFL | 
1 NON MCS i I i i i 
Se SS eS ae ee ie | ee ae oe 25 (Sas seme [S25 = ee= 4 
1 ZIPPED 1FMCS J=MCS1 /= | j { 
1 BY - { [sas=[(ee<e7 PMCS. 1 FsMcs { 
§}MCS i IFMCSUFCRF 1 i i 

OPEN.REPLY 

1 ALL | SOME OR ALL LSN'S BELONG TO 

I LON*S J A RF | 

LY AVAL [eee s eee Se Se SSS Se es ee nee | 

{ 1 RF=CRF | RF /= CRF 1 RF /= CRF $ 

1 i i PRIMARY { PRIMARY i 

i { i EMPTY i NO i 

i | j i SEC=MCS i 

—_ 1: 2 om on am oe on oo j ee ee ee ee ee ee ee ee ee ee ae a ee he a ee ee Ue ee Th UP —_— a wa j 
FROM NON 1 { 
MCS i DFL { 
<2 oo om = om a j se ae acaannaeawaeneee eeae ef 
FROM { ICRFICRF 1 i DETACH i 
MCS i A {= i s= 1 A 1 THEN ] 

i imMcsSimecS 1 | A { 

{ adie edema a 2 j 

I 1 Aitct 4] i { 

: LEGEND: 
; A - send approve to MCP | 
C - send ciose to MCS and deny open 


CRF - CONTROLLING REMOTE FILE If PRIMARY has HEADERS» 
then PRIMARY» else SECONDARY 

DFL = denys file tocked 

FCRF =- forward to CRF 

FMCS .~ forward to MCS 
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ATTACH MESSAGE 


The attach is a mechanism whereby new stations are assigned to an 
existing remote file. Whereas the open message aliows an initial 
assignment of stations to a new remote file» the attach protocol 
adds stations to the file subsequent to the open. | 


There are three important remote files (not necessarily unique) 
associated with an attach. 


1. The attach initiator begins the attach process by writing 
an attach message. Eventually he will expect to receive 
an attach.reply which wilt either approve or deny the 
attach. The station tist may be modified if the attach 
is forwarded to another MCS for approval so it may be 
necessary to review the station list in processing the 
completed attach. 


2. The attach object is the remote file to which the 
stations are being attached.j If the attach object is not 
the attach initiator» the open of the attach object must 
have been approved by the attach initiator. The attach 
object may or may not have headers. In either cases it 
receives no indication of the attach within the attach 
protocol » but may become aware of the attach via the 
inclusion of new stations in its normat message flows» via 
a remote-.fileeinfo» or via a user defined convention. In 
the case where this internal attach has been attempted» 
and the remote file for the MCS is full» an ATTACH.REPLY 
with DENY» MCS.FULL will be forwarded to the attach 
initiator. 


3- The controtting remote file (CRF) of a station is the 
file with headers to waich the station was most recently 
attached (Cor included in an open). If the primary has 
headers» it is the CRFs otherwise» the secondary file is 
the CRF if one exists. 


If the CRF of each = station in the stationedist is the attach 


initiator or nulls the attach is immediately processed and an 


attach.repiy sent back to the attach initiator. The signat char- 
acter specified in the attach will direct control messages to the 
attaching fiie for alt the stations he controts. 


If the controtling remote file for the stations in the attach is 
aremote file other than the attach initiators the attach message 


is forwarded to the CRF and, an attach.reply is expected in 


response. The CRF must approve or deny the attach and may modify 
the station tist of the attach. He also. Specifies the signal 


Character for all stations he controls. o This Sree Pee: Vs. 


If a 
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then reviewed by the NC» 
and processes it or denies it. 
is then sent on to the attach initiator. 
the attach but the NC denied it» a detach 
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with attach.replyeineerror set to "i". 


However e 


Station Is unattached» 


P. Se e21¢ 5447 (CF) 


which either approves the entire attach 
In either case» 


the attach.reply 


If another MCS approved 
is also sent to the CRF 


it may be included in an attach. 
when the attach is processed by the NC>» no 
will) be assigned. 


secondary 


if the stations in the stationelist have more than one CRF» the 
attach will be denied by the network controttler. 


ATTACH TABLE 


Fotlowing is 
the issuance 
attach.reply. 


 gncluded in the 


Participating or 
table 


a table indicating the status of 


attach and after 


because 


output7ontly 
stations attached in those two 


a station before 


the receipt of an 


stations are not 


classes do not change primary and secondary assignments. 


p= primary file 
S 


1 


secondary file 


self = attach initiator Cheaders) 74 
CRF = controlling remote file (not self) (headers) 


user = remote file 


CURRENT STATUS 


mm 2 1 oe on 8 ee oe ee ee a 


unattached 


p=nult»> s=nuil 


attached to self 


p=self 


attached to CRF 


p=CRF 


ATTACH TQ SELF 


status if approved 


p=self» s=nuil 
Signal.char ignored 
attachereply from NC 


p=sel f | 
Signai.char ignored 


attach.ereply from NC 


p=self» s=CRF 


attachereply sigechar. 


attach.reply from CRF 


whose open was approved by self (no headers) 


pelle TO oEnen FILE | 


Status if sauna 


p=others s=null 
signal.char ignored 
attachereply from NC 


p=others s=sel f 
attach signal.char 
attach.ereply from NC 


p= =other> Ss=CRF 


attach-reply sigechar. 
_attachereply from CRF 
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attached to file without headers 


Sh Wa a ee ee ee ee oe ee ee as es ee ee a a eo ee 


D— user »p 


 :p=user» 


p- user » 


MCS = attach 


attach denied by NC 


p=users s=null 
attach.repty from NC 


p=user» s=self_ 
signal.char ignored 
attachereply from NC 
p=self» s=CRF 


attachereply sSigechar 
attacherepiy from CRF 


Table 4.2 ATTACH 


MCS“NC 


W R 
MESSAGE.TYPE + & 
USER~REMOTE.FILE.NO + & 
ATTACHING. REMOTE.FILE.NO 
- SIGNAL.CHAR * s 
- APPROVE.DENY 
DENTAL REASON 
PROGRAM.J08.NO0 
 ATTACH.TIME 
- CURRENT.STATIONS + t 
 ATTACH.COUNT 
FILLER 
LSN.LIST + t 


CRF = controtting remote file 
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attach denied by NC 
p=user» s=nult 
attach.repty from NC 


p=others s=self . 
attach signal.char 
attach.reply from NC 


p=others» s=sel f 
attach.repiy sig»char 
attach.reply from CRF 


A 


» Fe 
=) 
m~ 
“J 
ned 


XC3) 
C999)# 


* 
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Table 4.3 ATTACH-REPLY 


| CRF-NO NC“-MCS 
sat W R W R PIC 
- MESSAGE.TYPE 4 & & 99 
USERsREMOTE.FILE.NO t & 999 
ATTACHING. REMOTE «FILE.NO s a 999 
SIGNAL.«CHAR « s k X 
 APPROVE.DENY + fe é t 9 
- DENTAL.REASON © t k 9 
- PROGRAM.JOB.NO a & 9{7) 
 ATTACH.TIME ‘ s 9(7) 
- CURRENT.»STATIONS * x & 999 
ATTACH. COUNT | r 999 
FILLER X(3) 
LSNeLIST & k & (999)8 


The semantics of the fields in the attach and attachserepty 


messages are simitar to the open with the fotlowing exceptions: 


ATTACHING.» REMOTE.FILE.NO The file number of the MCS originating 
the attach or attach.reply. It is set 
by the network controiter before 
forwarding the message to another MCS. 


 SIGNAL.CHAR set by the controtiling | remote ee  <{t 


is used by the network controtter to 
identify messages intended for the 
secondary file of a station. Blank 
implies no signal character. For previ- 
ously unattached stations and stations 
whose CRF a5 attaching to himself» the 
signal character is ignored. 


DENTIAL.REASON Set by the network controtter when an. 


attach is denieds- $[t may have the 
fotlowing values: 


"ov - MCS full 

"1" - invalid remote file 
"2" = file locked 

"3" = adapter missing 

"4" = CRF denied the attach 
"5" = (not used) 

"65" = invalid LSN in list 


"7" = too many MC5"s for one of the stations 
(the nesting oF the opens and attaches 


is too deep). 
"8" - attachereply error 
"jg" = too many Stations” in file 


PROGRAM. JOB-NO “4 On an attach is. ‘the job number of the 
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owner of the attaching remote file. On 


an attachereply this will be the job 
number of the controlling remote file. 
If this fietd corresponds to ones own 
file upon receiving an attachereply» the 
attach was approved by the network 
controller only. 


ATTACH.CNT The field reflects the actual number of 
LSNs that exist in the REMOTE_FILE. 
This number is used to determine’ the 
number of stations actuatly attached. 
Due to the PASS wsechanism»s LSNs are 
never removed from a remote file» even 
if a station is detached. Thus» while 
the MCS may attempt to attach 95 

stations» only 3 new LSNs may be added 
to the remote file. Because of this» 
the field is used by the MCS to. set 
REMOTE_FILE_CURRENT_STATIONS>» which is 
set only upon receiving the 
ATTACH.~REPLY. | 


ATTACH REVIEW CRITERTA 


Before an attach is approved without being sent to another MCS» 
the network controller verifies that: 


A. The remote file exists Cuser.remote»file.no is valid) | 


B. The attach initiator approved the open of the remote file 
or the attach initiator is the user remote file 


C. Current.stations +# the stations already attached to the 
file is dess than or equal to max.stations for that file 


De The following conditions are true: 


| 1. the station exists 
and 2.2 the adapter is present 
and 3. the station is appropriate» ies» that 


ae the old primary is nuil 
or be the old primary is the attach initiator 
or ce the old primary does not have headers and 
| the old secondary is the attach initiator 


and 4. the nesting of open approvals and attaches 1s 
not too deep A 

and 5. if the file is indicated as participatings the 
primary 1s ue attach initiator | 
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Before an attach is sent on to the controtling remote file (not 
the attach tnitiator) for approval» the network controlter veri- 
fies that: : 


Ae The remote fite exists Cuser.remote.efile.eno is valid) 


8B. The attach initiator approved the open of the remote file 
or the attach initiator 1s the user remote fite 


Ce. Currentestations # the stations already attached to the 
file is less than or equal to maxe.stations for that file 


D. fhe following conditions are true: 


ie the station exists 
and 2.2 the adapter is present 
and 3- the station iS appropriate» is@e» that 


ae the old primary is nuil Cnot all stations) 

or be the old primary is the controtling remote file 
or ce the old primary does not have headers and the 
old secondary is the controttling remote file 


and 46 the nesting of open approvals: and attaches is 
not too deep : 


Before an attachereply is processed and approved for the attach 
initiators the network controller verifies that: 


A. The remote file exists Cuser.remote.filesno is valid) 
8. The attach was forwarded to the CRF for approval 
C. The CRF set approve.deny to "1" indicating approval 


De. Current.stations + the stations already attached to the 
file is less than or equal to max.stations for that file 


E. The foilowing conditions are true: 


i.e the stations exist | 
and 22 the adapter is present 
and 3% the station is appropriates 1.@.e» that 


a» the odd primary is null 
or be the otd primary is the controlling remote file 
or ce the otd primary does not have headers and the 

| old secondary is the controlling remote file 


and 4. the nesting of open approvals and attaches. 
1s not too deep | 
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DETACH MESSAGE 


The detach is retated to the close in the same way that attach 15 


related to the open message. It is provided for negating the 


effect of an attach» removing stations from the station list of a 
remote file and returning them to their previous owners. 


If the user.remote.file.no is valid» the detach will be proces- 
sed» station by station» according to the following criterias 


1. A file may detach a station from itself. If there is a 
file which approved the open of that file» it is notified 
via the detach message forwarded by the network 


controller. This indicates to the receiving file that it 
is now the primary file again. 


2e A file may detach a station froma. a file ee attach or 
open it approved. 


3e When a station is detached from the remote file speci=- 
fied» it is aiso detached from ait files to which it had 
subsequently become attached. 7 


4. When an attach.replty has an errors a detach message is 


sent to the CRF with the attach.reply. in-error: “field ore 
This allows for three die tacene detach messages? 


1. Messages sent by a remote file with headers to detach a 
station from its file or a directly subordinate file. 
These detach messages wilt be responded to with a 
detacherepiy from the network controller» the LSN list 
indicating stations actually detached. | 


2. Messages sent by the network controtler to notify an MCS 
that it now controls a list of stationse No detachereply 
aS necessary. 


3. Messages sent by the network controtter to notify a CRF 
writing an attach.reply that the attach.~reply had an 
error and the attach did not get processed. No 
detach.reply is necessary. 
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DETACH AND CLEAR 


An MCS may request théet the LSN of a station being detached be 


removed from the FIB of the remote file. This actions which 


clears the LSN for the FI8"s station table» is catled the CLEAR 
option. It permits communication with any number of stations 
(not to exceed FIB.~REAL.MAX stations at any given time) instead 
of Limiting communication to the first stations that sign on or 
pass input to a program. As a result of this options once a 
Station is detached» messages cannot be written to that station. 


Some programs using the CLEAR option are subject to unexpected 
results. Programs that do not contain ON EDF branches for their 
remote file write statements are» upon attempting to writer 
detached by the MCP with an invatid key messages Also» programs 
using relative keys may incur a situation where the message i5 
sent to the wrong LSN. For examples if station A signs on to 
program X which employs relative keys in its remote file reads 
and writes» the MCS fires up program X and ptaces station A's LSN 
into the FIB. Consequently» whenever program X writes a response 
to RSN tl» the traffic is sent to station A. A problem occurs 
when a particular input request requires Lengthy processing time 


before program X returns aresponsee If station A signs off 


prior to receiving the responses that response could erroneously 


be directed to the wrong LSN. When the MCS issues the DETACH and 


CLEAR» the LSN is removed from the FIB. If station 3 signs on to 
program X before the response is ready» it will receive the 
message intended for station A. If program X sends the response 


after station A signs off and before station B signs ons an 


tnvatid key exception will occur. A simple detach wilt deliver 
the response to station A when the user signs on again. 


The following is the format of the detach message: 


Table 4.24 DETACH/DETACH.REPLY 


MCS=NC NC“NCS 
7 | WW R W R PIC 
- MESSAGE.TYPE © + t . & 99 
- -USER.REMOTEeFILE.NO + k & & 999 
ATTACH. REPLY.IN. ERROR i & 9 
CURRENT. STATIONS t+ & i . 999 
DETACH AND «CLEAR | , a & a 9 
FILLER | X(5) 


 LSNLLIST 7 + ie k «(99978 


- The semantics of the fields of the detach and detach-reply 
Messages are the same as fields in the OPEN message with the 
per Seka en 3 = 7 7 | 
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ATTACH-.REPLY~INW~ERROR A boolean which» when set to "1"» indi-~ 
. cates that the attachereply was in 
error » 
DETACH.AND.CLEAR A boolean which indicates to the NC and 
MCP the need to remove the LSN from the 
FIB. 


CLOSE MESSAGE 


The ctose message is provided as a negation to the open message. 


Close messages originate from the operating system and are passed 


to the remote file which approved the file open. Also» a close 
may be initiated by the network controiler if an open.erepty 
approving an open was in error (see OPEN). The close message 


requires no reply. 


If an MCS closes its file» the files whose opens it approved wiil 
also be closed. They will receive no new messages.» An end-of- 
file message is queued after the Last currently~queued messages 


The stations are relegated to the primary/secondary configuration 


which existed before the closed file was opened» The one excep 
tion to the above rule is when an MCS participates in user 
program I/Q» a ctose on the remote file does not atter the 
primary and secondary files for the station. | . ag8 4p pe 


Following is the format for the close message: 


Table 4.5 CLOSE 


NC-MCS 

W R PIC 
- MESSAGE.TYPE t a 99 
 CLOSE.TIME t te C7) 

PROGRAM. JOB.ND x * 9(7) 

— USER-REMOTE.F ILE.NO x sd 999 
 OPEN.WERROR te * 9 
- CURRENT.}STATIONS tk te 999 
FILLER > : x6) 
 LSNSLIST | a t (999) 


The semantics of the fields in the close message are similar to 


_ the open message with the exception: 


 OPEN.ERROR | A boolean set by the network controtler 
| to indicate that an MCS open approvat 
was tnvalid. | r = | 
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“SIAIUS MESSAGE 


Status is now only applicable to stations. The format of the 
station status/status.reply message is as foltows: 


Table 4.6 STATION STATUS REQUEST/REPLY 


MCS“NC NC“MCS 
W R W R PIC 
MESSAGE-TYPE + * * i 99 
LSN + te : te 999 
ss REQUESTING LSN ie te 999 
STATUS.ERROR = = & af 9 
STATION. NAME 7 = & i X¥(€10) 
 STATION.~READY as - & sl 9 
STATION ENABLED = as & * 9 
STATION MYUSE | a = * * =&9 
STATION. TERMINAL TYPE | = = & * 99 
~—STATIONJBUFFERSIZE . = % x 9(5) 
STATION. TRAN.NO.SIZE Pad = # & 9 
STATION. TRAN.JRECEIVE ; om _ te % XXX 
STATION~TRAN.TRANSMIT - * i XXX 
STATION.RECEIVE.ADDR.SIZE = “ * * 99 
STATION~TRANSMIT.~ADDR.SIZE ae = t * 99 
. STATION.ADOR.RECEIVE = = x al X€20) 
STATION. ADOR.TRANSMIT = = te X(20) 
STATION MAX.RETRIES | “= & & 999 
STATION.PRIORITY RECEIVE = - x * 999 
STATIONW~PRIORITY .TRANSMIT = = ve ke 999 
MESSAGE.CGUNT a _ te & 9(4) 
~=DIAGNOSTIC.REQ.ON ‘<j = el * 9 
 LOGICALACK.ON = - * & 9 
~ STATION.TALLIES - - te x 9(9) 
STATION. TOGGLES | = = te a 9(8) 
~~ STATION.REMOTE.FILE | | = = te i 999 
REMOTE.F ILE HASeHEADERS - = & * 9 
STATION. PHONE | = = * t X€20) 
STATION. VALID - = & 9 
— STATION-LINE.NDO a 7 fe sl 99 
STATION. oe ee US FILE.NO = = al ie 999 
FILLER | | XC10) 
LINE.COUNT | = * = & 99 
LINGE.INFO | - me & * C999)# 
LINE # 99 : . 
ACY 9 


It is noted that only message-type and LSN faeids are required 
for a valid status poseidon % | ie? | 
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The semantics of the status message fields are as fottlows: 


-LSN 
RE QUESTING.LSN 


STATUS»ERROR 
STATION. NAME 


STATION.» TALLIES 
STATION. TOGGLES 
STATIONREMOQTE.FILE 


REMOTE~FILE*«HAS»HEADERS 


STATION.PHONE 


 STATION.LINE.NO 


The togicat station number o f the 
station» the status of which 1s reques™ 
ted/provided. 


Provided for designating the station 
requesting the information. It is not 
required to be valid. 


Returned from the network controller and 
is "1" except when the LSN provided in 
the status request was invalids» in which 
case it is "0". 


Through ditagnostic.req.eon provides the 
same information as the station status 
reply message of previous releases» but 
in character format. 


Provides tallies 0-2 and toggles 0-7 in 
the same format as the data message. 


Indicates the number of the remote file 
to which normal input is attached. 


Indicates whether the above remote file 
was opened by an MCS-type program. 


The current phone number assigned to 
this statione Phone numbers are treated 
the same as with the NDL compiter. any 
invalid digit in the string is reptaced 
by the pause character (CFF hex). 


The current tine assignment for the 
Station. 


STATION.~SECONDARYFILE.NO The remote file number of the station's 


LINE .COUNT 


LINE .INFO 


secondary. If it is "000"» then there 
15 no secondary. , 


The number of lines on which the station 
is defined. 


Linesecount 3=-character fields describing 
the Line number (char 2) and its asso-~ 
ciated diatlout status boolean (char 1). 


A program with remote file headers may send a status message and 
receive ai corresponding status reply. | | 
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CHANGE MESSAGE 


The onty parameters subject to change are station change parame-~ 
terse Line attributes are opaque to an MCS. 


The format of the change and change-.reply is as follows: 
As of 820» an MCS may no tonger issue a CHANGE message affecting 


STATION-ENABLED. This flag its used internaily by the NC for 
queue management. 


Table 4.7 CHANGE/CHANGE.REPLY 


MESSAGE.TYPE + te re x 99 

LSWN + * * 999 

RE QUESTING«LSN | & * XXX 

CHANGE.TYPE + & k 99 

CHANGE.RESULT | | | ee a oe 

CHANGE .VALUE + te a ae X€20) or 

a - — XXX or 

999 or 
xX or 9 


(See chart below.) 


The semantics of the change message are as follows: 


LSN The station whose parameter is to be 
changed. 


 REQUESTING.LSN An optionat fietd provided for the LSN 

| of the station directing the change. 
This field is not used by the network 
controller and can contain information 
in any format desired. 


CHANGE.TYPE | | Indicates the field to be changed. The 
7 meanings are: 


CHANGE TYPE FIELD VALUE FORMAT 
"90" : TRANCRECEIVE) XX X 
"OL" .- FRANCTRANSMIT) 7 XXX 
"02" | ADDRESSCRECEI VE) x€20) 
ae! ee | ADDRESSCTRANSMIT)  X¥€ 20) 
"04" FREQUENCYCRECEIVE ) 999 
ull | Bo Seale FREQUENCY (TRANSMIT) 999 
"06" 7 NAX-RETRY — 999 


a: READY os 
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“99” | DIAGNOSTIC.ON 9 
710" LOGICALACK.ON 9 
i lg GOQDRESULTS.ON 9 
wie STATION.PHONE X€20) 
"15° SIGNAL»CHARACTER X 
— CHANGE.RESULT | Returns "1" untess there was an error in 
the message. "Oo" gjImoties an invalid 
LSN. "2" implies an invalid change 
type. 
 CHANGE.VALUE ~ The field's new value in left-justified 


character format. 
RECALL MES SAGE 


REMOVE MESSAGE 


The recall message is provided for removing any number of 


messages from the top of a station's output queues marking then 


as recalled.messages~» and sending thems prefixed by a 


- pecatl.repty message» to the MCS. The recail.repiy contains the 
number of messages to follow. : Bs 


The remove message is provided for removing any number of 
messages from the top of a station*s queue. The network 


fa controttier witl always respond with a remove.reply indicating the 
number of messages actually removed. 


A cautionary note: when using recadl and removers it 18 best to 
make the station not ready first as otherwise the first message 
May or may not be tncluded» depending on whether the station 15 
currently being processed. 


— Recails recaii.reply» remove and remove.reply messages are 
formatted as follows: 


Table 4.8 RECALL/RECALL.~REPLY 


MCS=NC NC-MCS 
. WOR WH OR PIC 
MESSAGE.TYPE ft #8 99 
—n |  #  & * = 999 
RE QUESTING.LSN “ ke 999 
- MESSAGE.COUNT | + & & te 9(4) 
— RECALL.JERROR | et 9 
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The semantics of the RECALL format are as foliows: 


 LSN | The station from whose output queue the 


messages are to be recalled or removed. 


 -REQUESTING.LSN This field indicates the station initi-~ 


ating the recail or remove. 


MESSAGE.COUNT Originatly the number of messages to be 
| recalled/ removed ("001" for one» 7999" 
for all) and inthe reply» the number of 

messages Seely Poeee co teow 


RECALL-ERROR Set to "1" af the message 1s tmpropertly 
| formulated. 


A recaid will place the recailed. messages immediately following 
the recail.reply. 


«REMOTE *FILE*INEO MESSAGE 


TIME 


An MCS“type program may control a set of stations by opening a 
remote file with the header option. In order to provide neces- 
Sar y information about the file just $acquired» the 
remoteefile.info/remote.file.info.reply protocol is provided. 
The format is as follows: | = ..* 


Table 4210 REMOTE.FILE-INFO/ REPLY 


MCS“NC NC- ‘MCS 
Ww R Ww R Pit 
 MESSAGE.TYPE + x k te 99 
— JOB.NO ft tk 9(7) 
: # ad 9(7) 
 . REMOTE.FILE.NO | +{#) & & * 999 
— « QUTPUT.MESSAGES. QUEUED * * 9C4) 
CURRENT. STATIONS it & 999 
 QTHER.RF.ERROR | : & te 9 
Oe NSAP EROVER SARS NO « & 99 
. FULLER 3 | 99 
LSNSLIST © | 7 ry i (999)#8 
 QUTPUT.QUEUED.LIST fe te (99978 


€#) Mandatory only if OTHER»RF REQUEST is “1°. 


[It is noted that only messageetype Is required for a valid 
_ wremote. -file.info raqgiey on the file SFr ar naby ag: ene SUR UEE Ye | 
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The semantics of the remaining fields are as follows: 


J0B.NO Job-number of the MCS~-type file. 
TIME The time that the reply was sent. 
REMOTE.FILE.NO The number of your remote file iif 
other.rferequest is "0". It is the 


number of the target remote. file if 
other.rferequest is "1". 


QOUTPUT.MESSAGES.  QUEUED The total of alt messages queued (for 
: output to att stattons in the file. 


INPUT.MESSAGES .QUEVED The total of atl messages queued from 
all stations that are destined to be 
read by your file. 


CURRENT.STATIONS The number of stations attached to the 
file. 
- OTHER.RF REQUEST "O" ¥f the request is for the writing 


MCS*s filesw It is "1" if remote.file.no 
contains the file number about which 
information is requested. | Dis 2 


OTHER.RF.ERROR "1" in the reply is the requestor had 


set other.rf.request to "1" and the 
remote.file.no suppiied was non~exis~ 


tente 
OPEN .APPROVER.RF .NO The remote file number of the MCS which 
approved the requestor's open. a 
LSN.LIST Has an LSN for every current station. 
— OUTPUT. QUEVED.LIST Has the output messages for each of the 
current stationse It should totai_ to 


outputemessages-equeued. 


LINE RELEASE MESSAGE 


The LINE.RELEASE message allows a user to request» through an 
MCS» that a tine (designated by a port» channel» and adapter 
triplet) be released from ownership by the network controitter. 
For instancer when a network controller initializes a multiline, 
adi fifteen adapters are tested for the existance of an Auto-catl 
unit CACU). ‘Since the NCP associates 1/0 ops with the program 


- issuing them» the network controller is considered the “owner” of 


all fifteen adapters. The user may decide to use one of these 
adapters for another program» such as RJE» HASP» or a second 
network controller. In order for the MCP to altow this» the 


lines that are not active must (first be released fron ownership 
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of the first network controller via the LINE.RELEASE message. 
A line is released when the fotlowing conditions are met. 

i. The NC owns the Line 

2» The Line status 1s 


ae idie or no messages are queued for a station on 
the Line. 


Ds and no station on the tine is enabled 

3 If a multiline exists and the request is for a Line 
with an ACU (the status of the ACU must not be “"in= 
use”). 


The format for LINE»RELEASE and LINEsRELEASE.REPLY is: 


Table 4.9 LINE.RELEASE/LINE.RELEASE.REPLY MESSAGE FORMAT 


NC-MCS_ MCS-N 

HW OR WOR! PIC 
MESSAGE.TYPE _ t 8 + oe 99 
REL»~PORT.~NUMBER * + x 9 
REL.CHANNEL.~NUMBER i + & 99 
REL~ADAPTER.~NUMBER te + & 99 
REL«RESULT eo x 


The semantics involved in the message format are: 


MESSAGE.}jTYPE "30" = LINE.RELEASE 

"Si" = LINE~RELEASE.REPLY 
REL.~PORT.NUMBER 
REL» CHANNEL.»NUMBER The triplet that describes the line to 
REL~ADAPTER.~jNUMBER be released. 
REL.RESULT "Oo" - Line released 


"1" - = not released» NC not owner of tine 


"2" - invalid parameters 
"3" =- not reteaed» NC using Line 
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COBOL74 NESSAGES 


CONTROL MESSAGES 


Additional control messages have been made available to implement 
ANSI COBOL74 within the B1000 datacomm framework. These messages 
only pertain to an MCS interacting within. a COBOL74 environment. 
Further reference should be made to the facilities described in 
the Communications Modute section of | the (CaBoL74 product speci- 
fications P.S. ee? aeets 


Tables 521 and 5.2 bist the messages and their types. 


Table 5.1 iescac es AeAe 


MESSAGE TYPE 
C74.CLOSE | | 16 
C74.0PEN | i8 
C74.-CREATE -QUEUE 34 
C74ENABLE DISABLE — | 36 


Table 5.2 MESSAGES WRITTEN 


MESSAGE © | TYPE 
C74.0PEN.REPLY 19 
C74CREATE .QUEVE.REPLY 35 
C74. ENABLE .OISABLE.REPLY Oo 37 
C74.DELETE QUEUE REPLY «3g 
C74 CLOSE 


When a COBOL74 program goes to E0J>» the MCP will generate a 


 .normal CLOSE message to the network controlter for each input 


- queue associated with the program. If there is an MCS that 
approved the open of this input queue then the network controlter 
will pass the CLOSE message to the MCS involved for informational 


purpose only. 


- Jf the MCS did not create the input queue and this COBOL74 


 -program is the last job associated with the input queue» the MCP 
will remove the queue. However» if the MCS created the queue 


- originally» then the MCP will not remove ite In the latter case» 
the MCS is expected to eventually issue a C74sDELETE. QUEUE 
_fequest to remove the queue. ee | . 


& 
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Tabie 5.3 lists the format for the CLOSE message. 


Table 5.3 C74 CLOSE FORMAT 


NC“MCS 

| W R PIC 
MESSAGESTYPE fe * 99. 
CLOSE. TIME * o 9(7) 
PROGRAM.»JOB.ND ie ie 9(7) 
USER. QUEUE .ND ke * 999 
OPEN.»ERROR * * 9 
CURRENT.~STATIONS x te 999 
COBOL74.F INAL * tk 9 
FILLER | XC5) 
LSNeLIST k te | (999) 


The semantics of the fields in a C74-CLOSE are the same as a 


normal close except that COBOL74.-FINAL is set to 1 by the MCP if 
the CLOSE applied to the tast COB0L74 job using USER~QUEUE.NO> 
and if USER.QUEVE.NO wasn't created by the MCS. 


Cf4 OPEN 


The MCP issues a C74.0PEN message to We feruenk ‘poateulier when 
a COBOL74 program executes either a RECEIVE statement or an 


ENABLE INPUT statement for a queue that does not exist» or for a 


queue that exists but with which the program has not been = asso- 
ciated. . 


Association of the program with the queue takes place impticitly 
upon the first ENABLE INPUT or RECELVE statement. Disassociation 
occurs when the program goes to E0NJ- | 


The network controller treats this message as an OPEN request. 
If there is an MCS involved» the network controttler witt forward 
the message to the MCS for approval. The network controtler then 
expects an C74&.0PEN.REPLY message from the MCS» and the network 
controlter wiit relay this C74.0PEN.REPLY message to the MCP via 
a DO_WRITE communicate. If the open request 1s approveds the MCP 
wild build a FIB for the queue at this point if one does not 
~ exist already. | | | 


_ Upon reinstatement» the COBOL74 program examines the status key 
in its input CD to determine the outcome. 


PASSWORDS 


- COBOL74 data communications makes provisions for the use of pass~ 


words. If the boolean PASSWORD. USED is sets the MCS. verifies the. 
validity — of the field. pee ronee. and if the | field is. invalids 
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C74&.0PEN is denied. If the boolean is not set» no action 158 


required of the MCS concerning passwords. 


SIMPLE -HEADERS 


The NC adtows a C74s0PEN only if SIMPLE.HEADER»OPTION and 
HEADER-«OPTION are set and if REMOTE.KEY is not set. 


PARTICIPATING 


COBOL74 data communications input queue opens may be approved as 
“participating” by an MCS. In this case» data input from 


Stations to these queues wittl be routed (by the network controt- 
ler) to the MCS that approved the open. Data output by a COBOL74 
SEND to stations wittl be routed (by the SMCP) to the MCS that 
approved any open for the COBOL74 program. Thus» participation 
on output messages will happen only after a queue open is 
approved oy the MCS. Participation on output messages 18 On a 


program basis rather than on a queue (file) basis because SENDs 


refer onty to a station (Cterminal or SYMBOLIC DESTINATION)» 
rather than to a queue or fite. Thus» if any input queue open 
for a COBOGL74 program (such as one of many) is approved as 
participating» att SEND output by that program will be sent to 
the MCS that first approved the open as “participating™ » instead 


of being sent directly to the station. 


Note that in order for the sending of partial messages or the 
sending of message segments to work correctly» according to 
COBOL74 ANSI standards» it is imperative that the MCS involved be 
a participating MC5e-  ##$The MCS is expected to tank partial 
messages or segments before sending a full message to a station. 
The 81000 MCP does not do the tanking. 


Table 5.24 lists the format for the COBOL74 open and its reply. 
Following the table is a list of fields that differ from a normal 
remote file open. 
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Table 5.4 


- MESSAGE.»TYPE 
 OPEN.TYPE 
OPEN.TIME 


PARENT.JOS~.NO 


 PROGRAM.JOB.NO 


PROGRAM.NAME 
HEADER.OPTION 

SIMPLE -HEADER. OPTION 
RE MOTE «KEY 

RESIDENT 


—- USER. QUEUE .ND 


SIGNAL «CHAR 
APPROV.DENY 
DENY.REASON 
PARTICIPATING 
GOOD.RESULTS 
MAXeSTATIONS 
CURRENT.»STATIONS 
LIST.TYPE 

FILE NAME 


 PROTOCOL.TYPE 


SESSION 
PASSWORD 


 PASSWORD.USED © 
- INPUT.Q.RECORD.SIZE 


INPUT.Q.8UFFERS 
INPUT.Q.DEPTH 
ESI 


FILLER 
-« STATIGONSLIST 


 MESSAGE.TYPE 


- PROGRAM.J0B.NO and 
- PROGRAM.NAME ~ 


 APPROVE.DENY 


- DENIAL.REASON 


NC“MCS 


* fF Ree eH HH HF 


nou 
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C74e0PEN/CT4.0PENeREPLY FORMATS 


MCS“NC 
W R PIC 
+ & 99 


+ ee & RD 
WO 


rd 
% ye eb OH re 
se a a ee 
O 
oO 
O 


ee * * ® FP HE HH HF 
és} 
a) 
) 
end 


+ £ ® » & 
* * & ® & 
o 
“~ 
i 
red 


X(7) 
(999)# 


C74.0PEN = "18% C74.0PEN.REPLY = "19" 


Wilt always contain the values 
associated with the COBOL74& program 
originating the run unite Thus» if the 


program for which this C74.0PEN has been 
issued was "CALLED™» its job number and 
name widl not be given... 


Set in the C74.0PEN.REPLY. 


"1" if approved. 
"0" if request is denied. 


Valid conty if APPROVE. ee Rs Set 
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by MCS =. = “L" af invalid @ keys = "2" 

1f invalid password. 
PASSWORD 1) If an “ENABLE INPUT <queue"name>* 
PASSWORD.USED caused CY74.0PEN to be generated» 
| PASSWORD is required and PASSWORD.USED = 

"1", 


2) If a "RECEIVE" <queue"name> statement 
was executed by a COBOL74 program» the 
C74.0PEN generated by the MCP will 
have PASSWORD set to ail blanks and 
PASSWORD.USED wild equat "0". 


INPUT.Q.-RECORD.SIZE Default vatue (Cequalts maximum buffer 
Size for any terminat on the line) is 
set by the NC. The MCS can aiter the 
value in the reply. 

INPUT.~Q2BUF FERS Default (2 buffers) is set by the NC 
before it forwards message to MCS. The 
later can aiter the vatue in the reply. 


INPUT.Q.DEPTH Set by NC and alterable by the MCS. 
| Default is 10. Se yf | 


C74. CREATE »QUEUVE 


This message» issued only by an MCS» causes the explicit creation 


of a COBOL queue. There are two intended uses for this message» 


one is for applications employing transactton"based routing 
CTBR)» and the other is for situations in which the MCS is aware 
of the future requirements for a specific queue or set of queues 
and can create them before they are actually needed. The reply 
from the NC indicates the remote file number of the queue just 
created. When the MCS schedules a COBOL74 job that will use a 
previousiy created queues the syntax for symbolic queue name. 
(SQN) 15 used. | 


An important difference exists between the Cf4.0PEN and the 
C74.CREATE.QUEUE requests. Tne creation of a queue via a 
~6CT4G2CREATE.QUEUE request does not give a COBOL74 program auto- 
Matic access to ite Moreover» a queue created explicitly by an 
MCS is not removed because there are no COS0L74 programs using it 


for data transfer. The queue is not closed until either the MCS 


goes to E0J» or until the MCS issues an explicit close. However» 
the queues built as a resuit of a C74.0PEN request» are destroyed 
when the last program having access to it goes to EQJ. 


The MCS is considerably flexible in Managing queuese If» for 
example» the MCS receives an OPEN request that was generated in 
response to a C74-0PEN for a currently nonexistent obese it has 
Ly two possible ad Cpending ener oval of the. ARENDS one option 
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is to issue the GPEN_REPLY and cause the creation of the queue 
which will grant access to the queue» or alternatively» the MCS 
can issue a C74&s*CREATE.QUEVE» wait for the C74eCREATEj»jQUEUE.RE- 


PLY» and return the OPEN_REPLY» thus retaining control over the 


queue. in the latter case» it is important that the MCS sets the 


ty. USEReQUEVUE.NG field in the C74.CREATE.QUEVE format to the same 
value of the USER. QUEVUE.NG field in the C74.0PEN format. 


The format for the C74.CREATE-QUEVE and C74.CREATE.QUEUE.REPLY is 
the same as the C74.0PEN except for the following fields. 


MESSAGE.«TYPE C74.CREATE»QUEUE = "34" 
C74.CREATEsQUEVEWREPLY = "35" 
INPUT. QsRECORD.SIZE If not set initiatty (that ise ="000") 
| Dy the MCS» the NC defaults the vatue to 
"2000". 
INPUT.Q.BUFFERS Same default as for C74. 
USER.~QUEUE.NQ Must be set to "090" if not created as a 


result of an open request, 


ECAsENASLE DISABLE 


COBOL?74 programs execute ENABLE/DISABLE state aeaes to modi fy the. 
logical connectivity between sources and destinations and the 


-. associated queues. There are two possibie input formats and one 
gutput format. For ainputes either the TERMINAL or <INPUT 
<queue“id> form is usede With the TERMINAL forms message 


transfer from that station is adlowed or disallowed accordingly. 


With INPUT <queueid>» the connection path is established/broken 
and an OPEN/CLOSE 1s appropriately issued by the MCP to the NC. 


«For outputs only the TERMINAL form is used. 


 ENABLE/DISABLE requests are forwarded to the NC by the MCP. If 


an MCS is present» the NC passes the request and waits for a 
reply. Requests of this type may not be generated by the ACS. 


If the request is togically valid and an MC5 is not involved» it 


will be granted. To be logically valid» the STATIOGN.NAME must 


 @xist within the datacomm network» and the station must aiready 
be attached to a COBOL74 queue. > 3 


The password option is an additional interaction that occurs 
between the ENABLE/DISABLE requests and the MCS. fhe administra- 
. tion of this option is the responsibility of the MCS. Within the 
- message is a i0-byte field which contains a character string. 


 Tabte 5.5 lists the format of the C74sENABLE.DISABLE request and 
is followed by a description of the various fieids. | 


Table 5.5 C7 4.ENABLE.DISASLE/C74.ENABLE.DISABLE-REPLY FORMATS — 
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 MESSAGE.TYPE « # + 99 
STATION.LSN | k  & & 999 
STATION.»NAME “ # x XC12) 
APPROVE .DENY kk + «& 9 
_ DENTAL.REASON | + «* 9 
FILLER | | 9 
PASSWORD sk X(10) 
PROGRAM. JOB.NO -« # « 9(7) 
ENABLE «DISABLE x 2 7 9 
USE « # & 9 
USER. QUEUE .ND & fe t 999 
USER sQUEUE «NAME - & ok X48) 


The meanings of the various fields are: 


MESSAGE.TYPE C74.ENABLE.DISABLE = "36" 
C74 ENABLE.~DISABLEsREPLY = "37" 


STATIOGN.LSN Valid onty if USE = "0" or USE = 1". 
| If not equal to *000"» then the LIN of 
Station affected. — 


STATION.NAME Valid only if USE = "0" or USE = "1". 
Identifier uniquely representing this 
station within the network controlter. 


- APPROVE.DENY | = "1" if request is approved. 
= "0" if request is denied. 


 DENIAL.REASON Valid only if APPROVE.DENY = 70”. 
= "1" if invalid queue (USE = "2") or 
if invalid station (USE = "0" or “1"). 
= "2" af invatid password. 


PASSWORD Character string sent from program to 
| MCS via MCP and NC to be used for pass= 
word validation. 


PROGRAM. J03.N0 | The job number of the COBOL74 program 
ane which originated the run unit (Cnot 
necessarily that issuing the request). 


ENABLE .DISABLE | = "1" if an ENABLE request. 
= "0" if a DISABLE request. 


USE | I/0 mode: 
| = "0" if QUIPUT. 
= "1" if INPUT TERMINAL. 
= "2" if INPUT <queue id>. 


USER.QUEUE<NO 0 22 Valid only if USE = "2". The user queue 


F Tees ca CS TEM UR HC UNE TT “Shap oon ht UMC emanate mer emia sre 
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number associated with USERQUEUE NAME. 


USER.QUEUVE .NAME Valid only if USE = "2". Name of the 


queue. 


C74 DELETE QUuEVE 
The C74 Delete Queue is used to remove a queue that was created 


via a C74-CREATE.QUEUVE. Onty an MCS may issue such a request. 
The format is described in Table 5.6. | 


Table 5.6 C/74&.~DELETE QUEUE .FORMAT 


MCSNC 

W R PIC 
MESSAGE.TYPE + & | 99 
USER QUEUE .NO + ie 999 


MESSAGE.FTYPE = "38" 


C74 DELETE QUEUE REPLY 


The C74 Delete Queue Reply that is returned to the MCS from the 


NC has the same format as a C74.CLOSE with the following mean- 
ings: | 


MESSAGE.TYPE =. Mog” 


 - PROGRAM.J08.NQO Set to the job number of the COBOL74— 


program originating the run untt. 


«USER -QUEVE .NO Same as USER.REMOTE.FILE.NO in a normal 


CLOSE message. 


OPEN.ERROR | | Set by NC to indicate action taken in 
response to request: 


"1° af no errors? queue removed. 


1 


be removed when released. Please note» 
however» that the MCS no tonger has 

any control over the queue. 

= "2" «Tf USER-QUEVE.NO was invatid. 


= "3" if the USER.QUEUE.NO specified in the 


request does not belong to the MC5-. 


— COBOL74.F INAL ss Set oby the NC to indicate whether there 


are any more COBOL74 programs using 
USERsQUEUENOS 


"QO" if USER.QUEUE.NO stil’ in uses it will 
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= "1" jf no more programs. 


“DATA MESSAGES 


To facilitate COBOL74» anew data message type has been created» 
in addition to the normal message. 


TYPE = "08" 


This is a regular data message except for the message type which 
equals “*08". An MCS which owns stations accessed (Cor to be 
accessed) by COBOL74 programs should be prepared to accept this 
message type. Such a message will be received infrequently since 
a precondition for its generator is an attempted SEND to a 
Station Cowned by this MCS) from which no COBOL74 program has yet 
done a RECEIVE. In this situations the MCP does not know whether . 
or not access to this station has previously been granted» ther- 
efores the message will be forwarded to the MCS who either sends 
it on to the station or discards it. However» the status key. 


fields when returned» atways indicates that the message was sent 


to the station and there is no reply expected from the MCS. 
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MCP ACTIONS UPON A COBOL74 RECEIVE OR ENABLE/DISABLE INPUT 


- The foliowing describes actions the MCP takes when a COBOL74 
program does a RECEIVE from an input queue or an ENABLE/DISABLE 
INPUT <queue id>. 


RECEIVE from an input queue: 
- If the queue does not exist» the MCP will first send a 
C74-0PEN message to the network controlter. 


-~ If the queue exists and the program is associated with 
the queues then the MCP wifi send the message if the 
queue 1s enabtled?s or 


- If the queue exists and the program is not associated 
with the queues then the MCP will first send a C74. OPEN 
possa9e to the network controlter. 


ENABLE INPUT <queue id>: 


- If the queue does not exist» the MCP wiil send a C74&.0PEN 
message to the network controiler. 


- If the queue exists and the program is associated with 
the queue» then the MCP will send a C74.~ENABLE.INPUT 
<queue id> message to the network controttlers or 


- If the queue exists and the program is not associated with. 
the MCP wiil send a C74. ane message to the network 
controtler. 


- DISABLE INPUT <queue id>: 


-~ If the queue does not exist» then the request is not honored 
with INVALID.Q.KEY as the reason. 


- If the queue exists and the program is associated with 
the queues then the MCP will send a C74e-DISABLE~INPUT 
<queue id> message to the network controtitler>s or 


- If the queue exists and the program is not associated 
with the queues then the request is not honored with 
INVALID. Qe-KEY as the reasone 
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Note that 


le. Associatior of the CO80L74 program with an input queue 
is established upon the RECEIVE statement or upon the 
first ENABLE INPUT <queue id>. 


2. Diassociatior of the COBOL74 program with an input queue 
does not occur upon a DISABLE INPUT <queue id>. Rather» 
if occurs when the program goes to E0NJ. 
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USER MESSAGES 
An executing MCS may interface with a user remote file without 
headers through the fotlowing record format: 


Table 6.1 USER*DEFINED MESSAGE 


NC“MCS = -MCS“NC WCS“USER USER@=MCS ~~ FIELD LENGTH 


| W R W R W R W R PIC 
MESSAGE.TYPE ik & + * + {*) (*«) * 99 
VARIANT ke & t te * _ = 9 
LSN i & x ik te (*) («) x 999 
TEXT.SIZE x *& + x + (*) (*) * 9(4) 
REMOTE.FILE.NO te te te oa + - = 999 
TIME & & = = 97) 
a TRAN.ND * te . 2 999 
\ ERROR * te - - XX 
| TALLYS te k 7 - 9(9) 
4 TOGGLES x ie & fe = - 9(3) 
TERMINAL.~TYPE te fe , = ” 99 
FILLER X(6) 
TE XT wk  &#& & & t * x x XCTEXT.SIZE) 


The semantics of the fields of the USER-DEFINED message record 
are: _ 


MESSAGE.FYPE | Established by the user program and must 
be a number greater than 49 and tess 
than 100, 
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APPROVE.DENY 4-59 Sw49 5-7 
ATTACH MESSAGE 4-11 

ATTACH REVIEW CRITERIA 4=15 
ATTACH TA@LE 4-22 

ATTACH.CNT 4-15 
ATTACH.REPLY.~INERROR 4-18 
ATTACHING»REMOTE.FILE.NO 4-14 


BASIC TERMINOLOGY as 


CHANGE MESSAGE 4-22 
CHANGE.RESULT 4-23 
CHANGE.TYPE 4-22 
CHANGE.VALUE 4-23 
CLOSE MESSAGE 4-19 
COBOL74 MESSAGES 5-1 


 COBOL74.FINAL 5-8 


CONTROL MESSAGES 4-1» 5-1 

CURRENT.»?STATIONS 4-6» 4°25 

C74 CLOSE 371 

C74 DELETE QUEUE a6 

C74 DELETE QUEUE REPLY 578 

C74 OPEN 5-2 
C74.2CREATE.QUEVUE 573 

CY4S4eENABLE.DLTSABLE 576 

DATA MESSAGES 3-1» 5-9 

DENTAL -.REASON 4-69 4-14» 5-4» 5-7 


DETACH AND CLEAR 4-18 


DETACH MESSAGE 4-17 
DETACH.AND.CLEAR 4719 
DUMMY REMOTE OPEN &=3 


-ENABLE.DISABLE 5-7 
END_LKEY 3-4 


ERROR 3-3 


«FILENAME «4-7 


GENERAL DESCRIPTION 1-1 
- GOOD.RESULTS 4-6 


- HEADER.OPTION 4=4 


INPUT.MESSAGES.QUEUED 4-25 
INPUT.»Q.BUFFERS 5-5* 5-6 
CINPUT.Q.DEPTH 5-5) 


4 


PARENT.J08.NO 


4 

bs 
PASSWORD 5°95» 5° 

5 
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INPUT.Q.eRECORD.SIZE 5-5» 5~6 


J0B.NO 4-25 


“KEY TO ABBREVIATION 2-2 


LINE RELEASE MESSAGE h=25 
LINE .COUNT 4-21 

LINE.INFQO 4-21 

LIST.~TYPE 4=-7 

LSN- 37359 421s 47220 4°24 
LSN.LIST h-25 


MAX.STATIONS 4-6 
MCP ACTIONS UPON A COBOL74 RECEIVE OR ENABLE/DLSABLE INPUT 5-10 
MESSAGE TYPES 2-1 

MESSAGE.COUNT 4-24 

MESSAGE.TYPE 6-1 


OPEN MESSAGE 4-1 

OPEN REPLY 4-1 

OPEN REVIEW CRITERIA 4-38 
OPEN WITH HEADERS 4-2 

OPEN WiThH SIMPLE HEADERS &-3 
OPEN.APPROVER.RF ND 4-25 
OPEN.~ERROR 4-19» 5-78 
OPEN~TIME 4-4 

OPEN.»TYPE 4n4 


OPEN/OPEN.REPLY FORMAT 4-3 
GTHER.RF.ERROR 4-25. 


OTHERRF ~zRE QUEST 4-25 
QUTPUT.MESSAGES. QUEUED 4-25 


— OQUTPUT.QUEVED.LIST 4-25 


4 

PARTICIPATING “be 575 
rf 
5 


PASSWORD.USED 
PASSWORDS 372 


— PROGRAM.JOB.NO = 4-45 4-149 S-4e 5-7> 5-8 


PROGRAM. NAME &n~4&» So4. 


PROTOCOL.TYPE = 47 


RECALL MESSAGE 4-23 


RECALL .ERRGR &-24 
RELATED DOCUMENTATION i-5 


REMAINDER.SQN 5-4 
REMOTE FILES 1-1 


— REMOTESFILESHAS.HEADERS «= 4721 
- -REMOTE.FILE.INFO MESSAGE 4-24 
REMOTE.FILE.ND 9 3-35 4-25 


REMOVE MESSAGE 4-23 


— REQUESTING.LSN 4-21» 4-225 4-24 
RESIDENT 4-5 — a 


i 
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RESGURCE SHARING’ 1-2 


SESSION 4-7 

SIGNAL.CHAR 4-55 4-14 
SIMPLEsHEADER»OPTION 4-5 
SIMPLEsHEADERS 5-3 
STATIONeLINE.NO 4721 
STATIONeLIST 4-7 
STATIONeLSN 5-7 
STATIONSNAME 4-215 5-7 
STATIONePHONE 4-21 
STATION.REMOTE.FILE 4-21 
STATION.SECONDARYsFILE.NO 4721 
STATIONeTALLIES 4-21 
STATION.TOGGLES 4-21 
STATUS MESSAGE 4-20 
STATUS»ERROR 47-21 


TALLY 374 
TERMINAL.TYPE 374 
TEXT 3-4 


TEXT.SIZE 5° 5 
TIME 3-39 4°25 
 YFOGGLE 574 
TRAN.NO 8 3°53 


USE 5-7 
- USESREMOTE.KEY = 4 
USER MESSAGES 6- 
 -USER.QUEUE.NO 5-8 
 USER.REMOTE.FILE.NO 475 


= 
1 


VARIANT 33 


